feat: add default production time#1072
feat: add default production time#1072tom-rm-meyer-ISST merged 6 commits intoeclipse-tractusx:mainfrom
Conversation
- added environment variables - created a utility to apply the default time to Date object - updated PlannedProductionCreationModal
tom-rm-meyer-ISST
left a comment
tom-rm-meyer-ISST
left a comment
There was a problem hiding this comment.
It's not working in local deployment. I locally fixed the frontend/.env.dockerbuild and added the DEFAULT_PRODUCTION_TIME to the docker compose setup for the frontend.
via npm works fine.
Please fix the local deployment. Further I would love if this feature is also considered during file upload (if no time is set, fallback to default).
- fix default production time in local deployment - update chart - update changelog
|
thanks again for your feedback and for pointing out the issues with the local deployment. I would like to briefly align on two conceptual points: 1. UTC vs. local timezone handlingCurrently, the backend operates in UTC, while the frontend works with the user’s local timezone. During Excel import, local timezones are also used. This means we are already mixing UTC (backend) and local time (frontend/import). For the sake of consistency, would you prefer that we standardize everything to UTC (e.g. always store and process in UTC and only convert for display in the UI)? Or should we explicitly define that production times are interpreted as local time and only converted to UTC at persistence level? I would appreciate your opinion on what you consider the cleaner and more consistent approach, so we can align on a clear rule going forward. 2. File upload in this PR or separate ticket?Applying the default production time during file upload (if no time is set) would extend the behavior beyond the current UI-based flow. Since the ticket scope focuses on introducing and configuring the default production time on application level (primarily affecting the default value in the UI), would you prefer to handle the import logic in a separate ticket? This would keep the current PR strictly aligned with the defined scope and avoid mixing UI default handling with import logic. Please let me know how you’d prefer to proceed. |
Hi @jakoballgaier, Sorry for the delay (sick leaves, vacations, other deadlines). Thanks for raising the technical debt and providing alternatives!
I would go with standardizing the backend to UTC and convert to local time zone in the UI. Here again the question arises, if this should be handled as a separate PR. If you want to handle it in another pr, feel free.
I would keep it in this PR. I would have seen it also in the ticket even if I fully see your point that it's more on the dynamics. Please incorporate and merge main (version bump needed). I'll handle your next changes prioritized to prevent further conflict resolving. |
|
Hey @jakoballgaier, @ReneSchroederLJ revealed the issue with time 0.00 to be defaulted during import. As this results in more hacking, you don't need ot incorporate the defaulting into the import fuctionality. Thanks for the analysis and sorry for any inconveniences. |
|
@tom-rm-meyer-ISST |
tom-rm-meyer-ISST
left a comment
tom-rm-meyer-ISST
left a comment
There was a problem hiding this comment.
Thanks for going through this with me! Works great! I likely need to wait till the reconfiguration of the required workflows is done. We disabled the workflow on purpose.
2 participants
Description
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:
changelog.md) with PR reference and brief summary.frontend/package.json,frontend/package-lock.json)backend/pom.xml)scripts/generate_openapi_yaml.pywith running customer backend)